1. Field of the Invention
This invention relates in general to graphics software construction, and in particular to immediate drawing interfaces.
2. Description of Related Art
In graphics software construction, renderers may be device drivers for virtual graphics devices. These virtual graphics devices, and their associated renderers, will have different capabilities--some might be photo-realistic, some might be especially fast, some will support hidden surface removal using a Z-buffer. They all essentially do the same things, such as draw lines, but they do them in different ways.
Existing renderers interact with specific devices. For example, a PCL (Printer Control Language) ADI (Autodesk Device Interface) renderer receives ADI commands from an application and provides PCL commands to a plotter. To draw figures on a screen, an application must provide commands to the particular renderer for that screen. This causes problems for the graphics software developer in that certain renderers may be better for some geometries, e.g., lines, while others may be better for other geometries, e.g., polygons. The developer must select one or the other.
Thus, there is a need in the art for a drawing interface that allows a graphics application to invoke multiple alternative renderers and graphics device drivers at run time. However, the ability to invoke multiple renderers at run time brings with it the need to manage versions of renderers. When the version of an interface between an application and a renderer changes, i.e., a new version of the interface is created, the renderer must be updated to adhere to the new interface or the application must continue to use the old interface. These are two distinct cases.
In the optimal situation, the renderer is updated to adhere to the new interface. When the renderer cannot be updated, the situation is sub-optimal, but accounting for the sub-optimal case should not impact the optimal case. That is, having a new application support an old renderer should not penalize the application's ability to use new renderers. The prior art, however, imposes an equivalent penalty on renderers, old and new alike. For example, the ADI pipeline handles driver versioning by always copying internal application data structures to the structures needed by the version of the renderer in use. This copying operation allows versioning to any new version, but it is at the expense of performance, and is always done, regardless of the renderer and application versions.
The Microsoft COM (Common Object Model) technology allows interfaces between software components to be modified while retaining the ability for an old component to talk to a new component. This is done through versioning of interfaces. The COM solution imposes an overhead burden that is unacceptable for graphics interfaces. This burden exists even for situations where an original interface has not been modified. In other words, the performance penalty is applied even for newly created components adhering to current interfaces. Thus, there is a need in the art for a drawing interface that provides improved versioning of interfaces.